Preserve typed PR pagination while fixing pull_request null classification #1046

Merged
coilyco-ops merged 2 commits from issue-991 into main 2026-07-10 19:57:40 +00:00
Member

closes #991\n\nward.workflow: pull-requests-and-merge

closes #991\n\nward.workflow: pull-requests-and-merge
fix: preserve typed PR pagination
All checks were successful
test / test (pull_request) Successful in 24s
fde33a122e
Author
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-claude-ward-1046 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness claude (reserved 2026-07-10T19:44:24Z). 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/ward#1046 · branch issue-1046 · harness claude · workflow pull-requests-and-merge
  • Run: engineer-claude-ward-1046 · ward v0.600.0 · dispatched 2026-07-10T19:44:24Z
  • 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.600.0).

— Claude (she/her), via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-claude-ward-1046` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness claude` (reserved 2026-07-10T19:44:24Z). 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/ward#1046` · branch `issue-1046` · harness `claude` · workflow `pull-requests-and-merge` - **Run:** `engineer-claude-ward-1046` · ward `v0.600.0` · dispatched `2026-07-10T19:44:24Z` - **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.600.0). </details> </details> <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Merge remote-tracking branch 'origin/main' into issue-991
All checks were successful
test / test (pull_request) Successful in 28s
88a60cb651
# Conflicts:
#	cmd/ward/configsource.go
Author
Member

WARD-OUTCOME: submitted

details

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

The in-container review gate was intentionally skipped because review gate skipped by ~/.ward/config.yaml default.

Repair run for PR #1046 (branch issue-991, closes #991): merged origin/main into the branch. The only conflict was a comment-only hunk in cmd/ward/configsource.go, resolved by taking main's post-ward#1009 text verbatim. No .ward/ward-kdl/ file was restored, recreated, or touched - the branch's diff against main is exactly the consumer change (listOpenPullRequests now reads listOpenIssueFeedByType(..., "pulls")) plus its tests in forgejo_ops_test.go and agent_director_merge_test.go. ward exec build/test/vet/lint all green; CI check test/test is green on head 88a60cb6 and the PR reports mergeable.

felt: clean surgical repair - main had already grown listOpenIssueFeedByType (ward#995), so the branch's consumer switch dropped in with a single trivial conflict.

confidence: high.

surprises: the first ward exec test run failed in cmd/ward but never reproduced across three subsequent runs including an uncached -count=1 full suite - looks like a cold-start flake, not this change. Also, an earlier git add -A briefly swept the container's .ward-run-provenance.json into the merge commit; caught and amended out before push.

follow-ups: none.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default The in-container review gate was intentionally skipped because review gate skipped by ~/.ward/config.yaml default. Repair run for PR #1046 (branch issue-991, closes #991): merged origin/main into the branch. The only conflict was a comment-only hunk in cmd/ward/configsource.go, resolved by taking main's post-ward#1009 text verbatim. No .ward/ward-kdl/ file was restored, recreated, or touched - the branch's diff against main is exactly the consumer change (listOpenPullRequests now reads listOpenIssueFeedByType(..., "pulls")) plus its tests in forgejo_ops_test.go and agent_director_merge_test.go. ward exec build/test/vet/lint all green; CI check test/test is green on head 88a60cb6 and the PR reports mergeable. felt: clean surgical repair - main had already grown listOpenIssueFeedByType (ward#995), so the branch's consumer switch dropped in with a single trivial conflict. confidence: high. surprises: the first ward exec test run failed in cmd/ward but never reproduced across three subsequent runs including an uncached -count=1 full suite - looks like a cold-start flake, not this change. Also, an earlier git add -A briefly swept the container's .ward-run-provenance.json into the merge commit; caught and amended out before push. follow-ups: none. </details>
Sign in to join this conversation.
No description provided.