Pin action-run list to page one #575
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/agentic-os#575
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The generated Forgejo Actions run list leaf sends --limit without an explicit page. Forgejo can ignore that limit on /actions/runs unless page=1 is present, which let agent CI checks dump thousands of historical runs. Shadow action-run list with the same safe page-1 behavior as the Actions listing bridge and document the mounted safe surfaces.
workflow: pull-request-and-merge
WARD-OUTCOME: done
PR: #576
Validation:
WARDED_WORKFLOW: qa-done ✅
qa details
verdict: pass
reviewed_sha:
reviewer_family: internal
workflow: pull-request-and-merge
issue_ref: coilyco-flight-deck/agentic-os#575
pr_ref:
reason: PR #576 at
9825a70ee2cbf1b6e0bdacadc2d4cb0fa251c7d2appears to satisfy issue #575. The patch shadowsward ops forgejo action-run listin both Forgejo guardfiles with a composite that hard-pinspage=1and threads through onlyowner,repo, and--limit, which fixes the reported unbounded run-list behavior without widening the ops surface. The docs and generated Forgejo reference were updated to point operators at the safe mounted surfaces, and Forgejo currently reports the PR checks green.evidence:
action list action-runwrappers to both.ward/guardfile.forgejo.kdland.ward/guardfile.forgejo.read.kdlthat call the underlying list op withpage "1"andlimit $limit.tasks listsafe-wrapper pattern instead of exposing the raw generated leaf, so the change narrows the callable surface rather than widening it.docs/forgejo-actions-listing.mdto distinguish the safeaction-run listandtasks listsurfaces from the role-scopedactions runsandactions tasksbridge surface.docs/ward-ops-forgejo-reference.mdnow showsward ops forgejo action-run listas a shadowed composite action with the safe page-one behavior, replacing the prior raw leaf description.tests/test_forgejo_actions_list_bridge.pyforward ops forgejo action-run list ... --limit 3 --dry-run, asserting the rendered URL contains/actions/runs?limit=3&page=1and does not leak the unexpanded${limit}placeholder.ci / gate (pull_request) = successandci / ward-doctor (pull_request) = success.risks:
.wardsurface viaWARD_CONFIG_REF, but it does not separately prove the mirrored.ward/guardfile.forgejo.read.kdlwrapper. The two guardfile edits are textually parallel, so this looks low risk rather than a blocker.next steps:
--dry-runcheck against the read-scoped surface would close the only remaining coverage gap.run_identity:
dispatcher framing:
Read the issue title, body, and comment thread below as the QA brief. Inspect the candidate branch, any linked pull request, and the available checks in the live repository state. Return a structured QA verdict that a human can read at a glance. Do not edit files, commit, push, or otherwise change implementation state.
Additional framing from the dispatcher:
Verify PR #576 fixes the Forgejo action-run list pagination issue without widening the ops surface.
— Codex, via
ward agentWARDED_WORKFLOW: #576
details
director merge authorization: reviewed-and-ready
workflow: pull-request-and-merge; review summary: passed: quick internal QA accepted PR #576 at
9825a70with green checkschecked head sha:
9825a70ee2status context: ci / gate=success, ci / ward-doctor=success
status state: success
Validation:
Retrospective: the fix was in the aos ward-spec bundle, not ward's native PR client. The remaining caveat is that the composite action no longer exposes the generated leaf's --query flag, but it prevents the unbounded run listing and keeps the surface narrow.