Fix PR log hooks to use executable Actions log identifiers #1388

New issue

Open

opened 2026-07-15 10:41:34 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-15 10:41:34 +00:00

Member

Problem

QA of #1270 / PR #1387 found that the new ward agent pr logs follow-up path does not work against the status object it emits.

Current-source smoke test on 2026-07-15 against merged PR #1387:

$ ward agent pr status coilyco-flight-deck/ward#1387 --json
latest_runs[0].id = 8470
latest_runs[0].index_in_repo = 2209
log_hooks[0].run_id = 2209
log_hooks[0].job_name = "0"
log_hooks[0].url = "/coilyco-flight-deck/ward/actions/runs/2209/jobs/0"

$ ward agent pr logs coilyco-flight-deck/ward#1387 --context "test / test (pull_request)"
forgejo get /api/v1/repos/coilyco-flight-deck/ward/actions/runs/2209/jobs/0/attempt/1/logs returned 404 Not Found

This means the agent-shaped object still leaks an unusable PR -> run -> job mapping. It parses the Forgejo UI run index/job placeholder rather than resolving an executable Actions log endpoint. That misses #1270's core requirement that agents can follow logs from the same object without manually mapping PR to commit SHA to run id to job id.

Acceptance criteria

ward agent pr logs <owner/repo#N> --context <context> works for the log hook emitted by ward agent pr status --json on a PR with a completed test run.
The status object distinguishes display run index from the API identifier actually accepted by the log endpoint, or otherwise emits only executable log-hook args.
When Ward cannot resolve job/attempt ids, the hook is available=false with a clear reason instead of an executable-looking hook that 404s.
Add regression coverage for the current #1387 shape: Actions run id differs from index_in_repo, and the status target URL contains a UI run path/job placeholder.
Preserve the existing wait and status behavior from #1387.

Follow-up from QA of #1270 / PR #1387. Labels intentionally copied from #1270 (headless, P1).

## Problem QA of #1270 / PR #1387 found that the new `ward agent pr logs` follow-up path does not work against the status object it emits. Current-source smoke test on 2026-07-15 against merged PR #1387: ```text $ ward agent pr status coilyco-flight-deck/ward#1387 --json latest_runs[0].id = 8470 latest_runs[0].index_in_repo = 2209 log_hooks[0].run_id = 2209 log_hooks[0].job_name = "0" log_hooks[0].url = "/coilyco-flight-deck/ward/actions/runs/2209/jobs/0" $ ward agent pr logs coilyco-flight-deck/ward#1387 --context "test / test (pull_request)" forgejo get /api/v1/repos/coilyco-flight-deck/ward/actions/runs/2209/jobs/0/attempt/1/logs returned 404 Not Found ``` This means the agent-shaped object still leaks an unusable PR -> run -> job mapping. It parses the Forgejo UI run index/job placeholder rather than resolving an executable Actions log endpoint. That misses #1270's core requirement that agents can follow logs from the same object without manually mapping PR to commit SHA to run id to job id. ## Acceptance criteria * `ward agent pr logs <owner/repo#N> --context <context>` works for the log hook emitted by `ward agent pr status --json` on a PR with a completed test run. * The status object distinguishes display run index from the API identifier actually accepted by the log endpoint, or otherwise emits only executable log-hook args. * When Ward cannot resolve job/attempt ids, the hook is `available=false` with a clear reason instead of an executable-looking hook that 404s. * Add regression coverage for the current #1387 shape: Actions run id differs from `index_in_repo`, and the status target URL contains a UI run path/job placeholder. * Preserve the existing `wait` and status behavior from #1387. ## Related Follow-up from QA of #1270 / PR #1387. Labels intentionally copied from #1270 (`headless`, `P1`).

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 10:41:34 +00:00

coilyco-ops added the

headless

labels

2026-07-15 10:41:34 +00:00

coilyco-ops commented

2026-07-15 10:41:56 +00:00

Author

Member

DISPATCH-DEFERRED: capacity blocked.

Attempted warded engineer coilyco-flight-deck/ward#1388 --harness codex from the QA director surface at 2026-07-15T10:41Z. The broker refused launch because the repo engineer limit is currently reached: 3 active engineer(s) (limit 3).

Dispatch log reported by ward: /Users/kai/.ward/agent-logs/dispatch/20260715T104138Z-director-codex-jp85-coilyco-flight-deck-ward-1388.log.

This issue remains queued for the burndown/director lane to dispatch when capacity opens.

DISPATCH-DEFERRED: capacity blocked. Attempted `warded engineer coilyco-flight-deck/ward#1388 --harness codex` from the QA director surface at 2026-07-15T10:41Z. The broker refused launch because the repo engineer limit is currently reached: `3 active engineer(s) (limit 3)`. Dispatch log reported by ward: `/Users/kai/.ward/agent-logs/dispatch/20260715T104138Z-director-codex-jp85-coilyco-flight-deck-ward-1388.log`. This issue remains queued for the burndown/director lane to dispatch when capacity opens.

coilyco-ops referenced this issue

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

Implement agent-shaped PR/CI status and wait primitives #1270

coilyco-ops commented

2026-07-15 12:21:37 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1388 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T12:21:37Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1388 · branch issue-1388 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1388 · ward v0.710.0 · dispatched 2026-07-15T12:21:29Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T10:41:56Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1388` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T12:21:37Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1388` · branch `issue-1388` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1388` · ward `v0.710.0` · dispatched `2026-07-15T12:21:29Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T10:41:56Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.710.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-15 12:32:43 +00:00

Fix PR log hook identifier resolution