coilyco-flight-deck/ward

Fork 0

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

New issue

Closed

opened 2026-07-14 10:09:01 +00:00 by coilyco-ops · 6 comments

coilyco-ops commented

2026-07-14 10:09:01 +00:00

Member

Parent

coilysiren/inbox#212

What to build

Implement an agent-shaped PR and CI status object, wait primitive, and log follow-up surface for the native workflow path, so agents stop composing low-level Forgejo calls and ad hoc sleep loops.

Kai confirmed on 2026-07-15 that status, wait, and logs are all core to meeting this need. Logs are annoying, but they are part of the useful first shape.

Before implementing, search cli-guard and agentic-os for prior PR/CI/log status tooling and reuse or adapt prior art where it fits.

Acceptance criteria

Ward exposes a compact PR/CI status primitive for agents, including PR number, head SHA, combined status, required status where available, failing contexts, pending contexts, latest run ids, log hooks, and next recommended action.
Ward exposes wait behavior: success on green, nonzero on failed or timeout, and useful output when still pending.
Ward exposes the log follow-up path from the same object so agents do not manually map PR to commit SHA to run id to job id.
Existing cli-guard and agentic-os CI/status/log tooling is reviewed and either reused, ported, or explicitly superseded.
Director merge and engineer handoff examples are added to the relevant help or docs surface.
Any large leftover primitive is split into a named follow-up issue.

Relationship to ward#1269

ward#1269 now tracks the broader discoverability/capability-manifest pressure test and is not a blocker for this P1. This issue should implement the ward-native status/wait/log surface first. Capability-registry projection can follow after ward#1269 is accepted.

Decision for headless carry

Kai confirmed this can be upgraded from design to implementation. Existing CI status tooling in aos and any relevant cli-guard prior art should be used as source material instead of drafting from scratch.

Required shape:

Implement agent-shaped PR/CI status, wait, and logs primitives rather than only writing a design.
Define and emit the status fields an agent needs: PR state, mergeability, required contexts, latest run conclusion, stale/head mismatch, failing contexts, run ids, log hooks, and next allowed action.
Keep wait behavior separate from status read behavior.
Prefer ward-native commands already present under ward agent pr where possible.
Add examples for director merge and engineer handoff.
File split implementation issues for any primitive that is too large.

## Parent coilysiren/inbox#212 ## What to build Implement an agent-shaped PR and CI status object, wait primitive, and log follow-up surface for the native workflow path, so agents stop composing low-level Forgejo calls and ad hoc sleep loops. Kai confirmed on 2026-07-15 that status, wait, and logs are all core to meeting this need. Logs are annoying, but they are part of the useful first shape. Before implementing, search cli-guard and agentic-os for prior PR/CI/log status tooling and reuse or adapt prior art where it fits. ## Acceptance criteria - [ ] Ward exposes a compact PR/CI status primitive for agents, including PR number, head SHA, combined status, required status where available, failing contexts, pending contexts, latest run ids, log hooks, and next recommended action. - [ ] Ward exposes wait behavior: success on green, nonzero on failed or timeout, and useful output when still pending. - [ ] Ward exposes the log follow-up path from the same object so agents do not manually map PR to commit SHA to run id to job id. - [ ] Existing cli-guard and agentic-os CI/status/log tooling is reviewed and either reused, ported, or explicitly superseded. - [ ] Director merge and engineer handoff examples are added to the relevant help or docs surface. - [ ] Any large leftover primitive is split into a named follow-up issue. ## Relationship to ward#1269 ward#1269 now tracks the broader discoverability/capability-manifest pressure test and is not a blocker for this P1. This issue should implement the ward-native status/wait/log surface first. Capability-registry projection can follow after ward#1269 is accepted. --- ## Decision for headless carry Kai confirmed this can be upgraded from design to implementation. Existing CI status tooling in aos and any relevant cli-guard prior art should be used as source material instead of drafting from scratch. Required shape: * Implement agent-shaped PR/CI status, wait, and logs primitives rather than only writing a design. * Define and emit the status fields an agent needs: PR state, mergeability, required contexts, latest run conclusion, stale/head mismatch, failing contexts, run ids, log hooks, and next allowed action. * Keep wait behavior separate from status read behavior. * Prefer ward-native commands already present under `ward agent pr` where possible. * Add examples for director merge and engineer handoff. * File split implementation issues for any primitive that is too large.

coilyco-ops added the

consult

labels

2026-07-14 10:09:01 +00:00

coilyco-ops commented

2026-07-14 10:15:40 +00:00

Author

Member

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

Recommendation

Design this as a Ward-owned structured capability, not as another ward ops forgejo leaf. The useful unit is a single PRCIStatus object produced by pr.status, reused by pr.wait, and carrying log hooks that Ward can execute without the agent mapping PR -> commit -> run -> job -> attempt.

Current code already has most raw inputs in Ward: GetPullRequest, GetCommitCombinedStatus, GetBranch, ListActionRuns, PR repair classification, native ward agent pr status, and broker forwarding from read-only director surfaces. The gap is shape and orchestration, not forge reach.

Status Object

Recommended compact JSON shape:

{
  "repo": "coilyco-flight-deck/ward",
  "pr": {"number": 123, "title": "...", "url": "...", "state": "open", "draft": false},
  "base": {"ref": "main", "required_contexts": ["test", "vet", "lint"]},
  "head": {"ref": "feature", "sha": "abc123"},
  "status": {
    "combined": "failure",
    "required": "failure",
    "terminal": true,
    "observed_at": "2026-07-14T10:30:00Z"
  },
  "contexts": [
    {"name": "test", "state": "failure", "required": true, "description": "...", "target_url": "...", "run_id": 42}
  ],
  "failing_contexts": ["test"],
  "pending_contexts": [],
  "latest_runs": [
    {"id": 42, "index": 7, "workflow_id": "test", "status": "failure", "event": "pull_request", "commit_sha": "abc123", "url": "..."}
  ],
  "log_hooks": [
    {"context": "test", "capability": "ci.log.read", "args": {"repo": "coilyco-flight-deck/ward", "run_id": 42, "context": "test"}}
  ],
  "repair": {"bucket": "pr-regression", "note": "workflow test is mirrored locally and origin/main is green"},
  "next_action": "fetch_logs"
}

Key decisions:

Keep both combined and required status. Merge and wait decisions should use required contexts when branch protection exposes them. Fall back to combined status only when required contexts are unavailable.
Treat missing contexts as pending, not success. A PR with no reported status contexts is still waiting.
Filter latest Actions runs by the current PR head SHA. Do not let a green run for an older SHA satisfy the wait.
Include next_action as a small enum: wait, fetch_logs, rerun_ci, repair_pr, rebase_or_refresh, merge, blocked, none.
Keep log retrieval as hooks, not command strings. Hooks can render a CLI hint for humans, but the machine contract should be capability ID plus structured args.

Wait Primitive

Add pr.wait as the same status builder plus a polling loop. A CLI wrapper can be ward agent pr wait <owner/repo#N> --timeout 30m --interval 15s --json.

Behavior:

Exit 0 only when the current PR head is green for the required status set.
Exit nonzero immediately on terminal red states: failure, error, cancelled, or a required context skipped in a way Ward treats as blocking.
Exit nonzero on timeout, with the final PRCIStatus object printed so the agent sees pending contexts and log hooks.
While pending, print compact progress in text mode and emit only the final object in JSON mode. A useful text line is: coilyco-flight-deck/ward#123 head abc123 required=pending pending=test,lint latest_runs=42,43 next=wait.
If the PR head changes during the wait, reset the poll state and continue against the new head. Add --head SHA for callers that want fail-fast head pinning.
Recommended exit codes: 0 green, 1 terminal red, 124 timeout, 2 usage or auth/config failure.

The wait loop should live in Ward, not in the broker. On a read-only director surface, each poll can call the brokered status capability. That keeps the broker stateless and avoids holding one long socket open.

Log Hooks

The object should make log retrieval a direct follow-up:

ci.log.read should accept repo plus run_id and optional context or job_name.
Ward should resolve run -> job -> latest attempt internally.
The agent should never need to call raw ward ops forgejo actions logs <owner> <repo> <run> <job> <attempt>.
The existing raw actions log leaf proves the forge can serve logs, but it is the wrong agent contract because it exposes job and attempt IDs.
If Ward cannot resolve a job yet, the hook should still say available: false with the reason, while preserving the run id and target URL.

What Can Land Now

Add an internal PRCIStatus builder in Ward using the existing Forgejo client methods.
Add ward agent pr status --json while preserving the current human text output.
Add ward agent pr wait as a native wrapper around the builder.
Filter runs by PR head SHA and attach run IDs to contexts where workflow names match contexts.
Reuse existing PR repair buckets in the object.
Add tests around green, red, missing statuses, stale run SHA, required vs optional contexts, and timeout.

What Depends On ward#1269

Publishing pr.status, pr.wait, ci.log.read, and ci.run.rerun in the capability registry.
Returning this object through the post-ward ops broker execute path.
Exposing role gates, provider availability, and streaming metadata in discovery.
Making log hooks executable through capability IDs instead of CLI argv shims.

Options Considered

Text-only ward agent pr status plus shell sleep loops - reject. It preserves the current agent failure mode.
Raw Forgejo-shaped JSON - reject. It leaks provider mapping and forces agents to join unrelated endpoints.
One run-centric CI object - reject as the primary shape. Agents start from a PR and need PR, head, required contexts, runs, and logs together.
Broker-side long wait - defer. It can be added later, but the first version should keep broker calls short and idempotent.
Ward-owned PRCIStatus object with wait wrapper - recommend. It matches the current native PR-workflow direction and can land incrementally.

Open Questions

Confirm the exact Forgejo endpoint Ward should use to list run jobs and attempts. The raw log route exists, but the native resolver needs job discovery.
Decide whether skipped is always terminal red for required contexts or only red for protected required contexts.
Decide default timeout. Recommendation: 30 minutes, with --timeout 0 meaning one status read and no wait.
Decide whether JSON mode prints pending snapshots as JSON lines or only the final object. Recommendation: final object only by default, optional --watch-jsonl later.
Decide whether GitHub support is declared unavailable in the object or omitted until provider work exists. Recommendation: declare provider availability explicitly through ward#1269.

Risks

Combined status can hide the required-context rule. The object needs both.
Actions run feeds can lag behind commit statuses. Status contexts remain authoritative for pass/fail, while runs enrich logs and reruns.
A green status for an old SHA can cause unsafe merge advice. Every decision must key off the current head SHA.
Raw log URLs or low-level log args will recreate the mapping problem. Use hooks.
Long waits through the director broker can become fragile if implemented as one held connection.
Compatibility aliases can become the de facto API unless the new capability IDs are the documented agent contract.

Follow-Up Implementation Tickets

ward: Add PRCIStatus builder and tests for required, combined, failing, pending, stale-SHA, and no-status cases.
ward: Add ward agent pr status --json using PRCIStatus.
ward: Add ward agent pr wait with timeout, interval, head-change handling, and exit codes.
ward: Add native Actions job/log resolver and ci.log.read hook generation.
ward: After ward#1269, expose pr.status, pr.wait, ci.log.read, and ci.run.rerun through the capability registry and broker execute path.
ward: Document the object and wait semantics in docs/agent-pr-workflow.md.

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- **Recommendation** Design this as a Ward-owned structured capability, not as another `ward ops forgejo` leaf. The useful unit is a single `PRCIStatus` object produced by `pr.status`, reused by `pr.wait`, and carrying log hooks that Ward can execute without the agent mapping PR -> commit -> run -> job -> attempt. Current code already has most raw inputs in Ward: `GetPullRequest`, `GetCommitCombinedStatus`, `GetBranch`, `ListActionRuns`, PR repair classification, native `ward agent pr status`, and broker forwarding from read-only director surfaces. The gap is shape and orchestration, not forge reach. **Status Object** Recommended compact JSON shape: ```json { "repo": "coilyco-flight-deck/ward", "pr": {"number": 123, "title": "...", "url": "...", "state": "open", "draft": false}, "base": {"ref": "main", "required_contexts": ["test", "vet", "lint"]}, "head": {"ref": "feature", "sha": "abc123"}, "status": { "combined": "failure", "required": "failure", "terminal": true, "observed_at": "2026-07-14T10:30:00Z" }, "contexts": [ {"name": "test", "state": "failure", "required": true, "description": "...", "target_url": "...", "run_id": 42} ], "failing_contexts": ["test"], "pending_contexts": [], "latest_runs": [ {"id": 42, "index": 7, "workflow_id": "test", "status": "failure", "event": "pull_request", "commit_sha": "abc123", "url": "..."} ], "log_hooks": [ {"context": "test", "capability": "ci.log.read", "args": {"repo": "coilyco-flight-deck/ward", "run_id": 42, "context": "test"}} ], "repair": {"bucket": "pr-regression", "note": "workflow test is mirrored locally and origin/main is green"}, "next_action": "fetch_logs" } ``` Key decisions: * Keep both `combined` and `required` status. Merge and wait decisions should use required contexts when branch protection exposes them. Fall back to combined status only when required contexts are unavailable. * Treat missing contexts as `pending`, not success. A PR with no reported status contexts is still waiting. * Filter latest Actions runs by the current PR head SHA. Do not let a green run for an older SHA satisfy the wait. * Include `next_action` as a small enum: `wait`, `fetch_logs`, `rerun_ci`, `repair_pr`, `rebase_or_refresh`, `merge`, `blocked`, `none`. * Keep log retrieval as hooks, not command strings. Hooks can render a CLI hint for humans, but the machine contract should be capability ID plus structured args. **Wait Primitive** Add `pr.wait` as the same status builder plus a polling loop. A CLI wrapper can be `ward agent pr wait <owner/repo#N> --timeout 30m --interval 15s --json`. Behavior: * Exit `0` only when the current PR head is green for the required status set. * Exit nonzero immediately on terminal red states: failure, error, cancelled, or a required context skipped in a way Ward treats as blocking. * Exit nonzero on timeout, with the final `PRCIStatus` object printed so the agent sees pending contexts and log hooks. * While pending, print compact progress in text mode and emit only the final object in JSON mode. A useful text line is: `coilyco-flight-deck/ward#123 head abc123 required=pending pending=test,lint latest_runs=42,43 next=wait`. * If the PR head changes during the wait, reset the poll state and continue against the new head. Add `--head SHA` for callers that want fail-fast head pinning. * Recommended exit codes: `0` green, `1` terminal red, `124` timeout, `2` usage or auth/config failure. The wait loop should live in Ward, not in the broker. On a read-only director surface, each poll can call the brokered status capability. That keeps the broker stateless and avoids holding one long socket open. **Log Hooks** The object should make log retrieval a direct follow-up: * `ci.log.read` should accept repo plus `run_id` and optional `context` or `job_name`. * Ward should resolve run -> job -> latest attempt internally. * The agent should never need to call raw `ward ops forgejo actions logs <owner> <repo> <run> <job> <attempt>`. * The existing raw actions log leaf proves the forge can serve logs, but it is the wrong agent contract because it exposes job and attempt IDs. * If Ward cannot resolve a job yet, the hook should still say `available: false` with the reason, while preserving the run id and target URL. **What Can Land Now** * Add an internal `PRCIStatus` builder in Ward using the existing Forgejo client methods. * Add `ward agent pr status --json` while preserving the current human text output. * Add `ward agent pr wait` as a native wrapper around the builder. * Filter runs by PR head SHA and attach run IDs to contexts where workflow names match contexts. * Reuse existing PR repair buckets in the object. * Add tests around green, red, missing statuses, stale run SHA, required vs optional contexts, and timeout. **What Depends On ward#1269** * Publishing `pr.status`, `pr.wait`, `ci.log.read`, and `ci.run.rerun` in the capability registry. * Returning this object through the post-`ward ops` broker execute path. * Exposing role gates, provider availability, and streaming metadata in discovery. * Making log hooks executable through capability IDs instead of CLI argv shims. **Options Considered** * Text-only `ward agent pr status` plus shell sleep loops - reject. It preserves the current agent failure mode. * Raw Forgejo-shaped JSON - reject. It leaks provider mapping and forces agents to join unrelated endpoints. * One run-centric CI object - reject as the primary shape. Agents start from a PR and need PR, head, required contexts, runs, and logs together. * Broker-side long wait - defer. It can be added later, but the first version should keep broker calls short and idempotent. * Ward-owned `PRCIStatus` object with wait wrapper - recommend. It matches the current native PR-workflow direction and can land incrementally. **Open Questions** * Confirm the exact Forgejo endpoint Ward should use to list run jobs and attempts. The raw log route exists, but the native resolver needs job discovery. * Decide whether `skipped` is always terminal red for required contexts or only red for protected required contexts. * Decide default timeout. Recommendation: 30 minutes, with `--timeout 0` meaning one status read and no wait. * Decide whether JSON mode prints pending snapshots as JSON lines or only the final object. Recommendation: final object only by default, optional `--watch-jsonl` later. * Decide whether GitHub support is declared unavailable in the object or omitted until provider work exists. Recommendation: declare provider availability explicitly through ward#1269. **Risks** * Combined status can hide the required-context rule. The object needs both. * Actions run feeds can lag behind commit statuses. Status contexts remain authoritative for pass/fail, while runs enrich logs and reruns. * A green status for an old SHA can cause unsafe merge advice. Every decision must key off the current head SHA. * Raw log URLs or low-level log args will recreate the mapping problem. Use hooks. * Long waits through the director broker can become fragile if implemented as one held connection. * Compatibility aliases can become the de facto API unless the new capability IDs are the documented agent contract. **Follow-Up Implementation Tickets** * `ward`: Add `PRCIStatus` builder and tests for required, combined, failing, pending, stale-SHA, and no-status cases. * `ward`: Add `ward agent pr status --json` using `PRCIStatus`. * `ward`: Add `ward agent pr wait` with timeout, interval, head-change handling, and exit codes. * `ward`: Add native Actions job/log resolver and `ci.log.read` hook generation. * `ward`: After ward#1269, expose `pr.status`, `pr.wait`, `ci.log.read`, and `ci.run.rerun` through the capability registry and broker execute path. * `ward`: Document the object and wait semantics in `docs/agent-pr-workflow.md`. --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

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

2026-07-15 05:14:50 +00:00

coilyco-ops added

headless

and removed

consult

labels

2026-07-15 06:03:41 +00:00

coilyco-ops changed title from ~~Design agent-shaped PR/CI status and wait primitives~~ to Implement agent-shaped PR/CI status and wait primitives

2026-07-15 06:26:54 +00:00

coilyco-ops commented

2026-07-15 07:08:46 +00:00

Author

Member

P1 clarity note from Kai on 2026-07-15: status, wait, and logs are all core to meeting the need. Logs are annoying but should not be silently deferred from the first useful design. Before implementing, search cli-guard and agentic-os for prior PR/CI/log status tooling and reuse or adapt prior art where it fits.

coilyco-ops commented

2026-07-15 07:16:37 +00:00

Author

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 10:02:57 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T10:02:57Z). 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#1270 · branch issue-1270 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1270 · ward v0.710.0 · dispatched 2026-07-15T10:02:49Z
Comment thread: 3 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-14T10:15:40Z), @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:37Z)

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-1270` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T10:02:57Z). 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#1270` · branch `issue-1270` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1270` · ward `v0.710.0` · dispatched `2026-07-15T10:02:49Z` - **Comment thread:** 3 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-14T10:15:40Z), @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:37Z) 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 pull request that will close it,

2026-07-15 10:36:46 +00:00

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

coilyco-ops closed this issue

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

coilyco-ops commented

2026-07-15 10:38:58 +00:00

Author

Member

WARDED_WORKFLOW: #1387

details

workflow: pull-request-and-merge; review summary: skipped
review gate intentionally skipped because temporary ward default pending brokered QA.
felt: implementation was direct but the lint gates forced a couple of small refactors.
confidence: high
surprises: ForgejoGraphQL is not usable here; REST was the stable path.
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1387 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped review gate intentionally skipped because temporary ward default pending brokered QA. felt: implementation was direct but the lint gates forced a couple of small refactors. confidence: high surprises: ForgejoGraphQL is not usable here; REST was the stable path. follow-ups: none </details>

coilyco-ops referenced this issue

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

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

coilyco-ops commented

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

Author

Member

QA follow-up: FAIL. PR #1387 merged at cef1a86a6c and its PR test/promote passed, but it does not satisfy the log follow-up acceptance for #1270.

Evidence from current source after merge:

ward agent pr status coilyco-flight-deck/ward#1387 --json emitted latest_runs[0].id=8470, latest_runs[0].index_in_repo=2209, but log_hooks[0].run_id=2209, job_name="0", and URL /actions/runs/2209/jobs/0.
ward agent pr wait coilyco-flight-deck/ward#1387 --timeout 0s --json exited 0, so the status/wait path is present.
ward agent pr logs coilyco-flight-deck/ward#1387 --context "test / test (pull_request)" failed with GET /api/v1/repos/coilyco-flight-deck/ward/actions/runs/2209/jobs/0/attempt/1/logs returned 404 Not Found.

That means the status object still emits an executable-looking log hook that does not work, leaving agents with the same run/job mapping problem #1270 was meant to remove.

Filed follow-up #1388 with labels copied from this issue (headless, P1) and milestone 9. Dispatch was attempted immediately but capacity was full (3 active engineer(s) (limit 3)), so #1388 has a DISPATCH-DEFERRED note with the broker log path.

QA follow-up: FAIL. PR #1387 merged at cef1a86a6cb0eeabd70131cf41311f9ae45c547e and its PR test/promote passed, but it does not satisfy the log follow-up acceptance for #1270. Evidence from current source after merge: - `ward agent pr status coilyco-flight-deck/ward#1387 --json` emitted `latest_runs[0].id=8470`, `latest_runs[0].index_in_repo=2209`, but `log_hooks[0].run_id=2209`, `job_name="0"`, and URL `/actions/runs/2209/jobs/0`. - `ward agent pr wait coilyco-flight-deck/ward#1387 --timeout 0s --json` exited 0, so the status/wait path is present. - `ward agent pr logs coilyco-flight-deck/ward#1387 --context "test / test (pull_request)"` failed with `GET /api/v1/repos/coilyco-flight-deck/ward/actions/runs/2209/jobs/0/attempt/1/logs returned 404 Not Found`. That means the status object still emits an executable-looking log hook that does not work, leaving agents with the same run/job mapping problem #1270 was meant to remove. Filed follow-up #1388 with labels copied from this issue (`headless`, `P1`) and milestone 9. Dispatch was attempted immediately but capacity was full (`3 active engineer(s) (limit 3)`), so #1388 has a `DISPATCH-DEFERRED` note with the broker log path.