coilyco-flight-deck/ward

Archived

Watch

Include open PRs in director managed burndown scope #804

Closed

opened 2026-07-09 15:49:57 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 15:49:57 +00:00

Owner

Director's managed headless burndown currently refreshes only open issues via listOpenIssues / backlogRefresh. Open PRs are handled by a separate director merge sweep, and only the narrow pull-request-and-merge marker path can auto-merge. That leaves ordinary open PRs invisible to the interactive director backlog even when they are the actual work blocking release.

Motivating example: PR #773 was open for issue #735, but ward agent director merge --repo coilyco-flight-deck/ward --dry-run skipped it because the PR body lacked ward.workflow: pull-request-and-merge. The director backlog also did not surface it as headless work because PRs are not folded into the managed scope.

Request: add open PRs to the director-managed headless automated burndown scope.

Expected behavior:

Director refresh includes open PRs alongside open issues for each scoped repo.
PR entries are visible in backlogPrintStatus / dry-run output with enough identity to distinguish PR #N from issue #N.
PRs that already have a merge-authorized pull-request-and-merge marker can continue through the existing narrow auto-merge lane.
Ordinary open PRs should still be tracked and surfaced as work: if checks fail, stale, or review/merge state blocks them, director should queue/surface the PR follow-up instead of reporting an empty headless lane.
The implementation should avoid dispatching an engineer against a PR as if it were the original issue unless the seed explicitly tells the worker to update the existing PR branch and preserve the PR boundary.

Implementation notes from the current code:

cmd/ward/agent_director.go backlogRefresh only calls cl.listOpenIssues and ranks issue labels.
cmd/ward/forgejo_ops.go already has listOpenPullRequests for the merge lane.
cmd/ward/agent_director_merge.go holds the current merge eligibility policy. Keep that policy for actual merge authority, but make non-eligible open PRs visible to the director loop.
Update docs: docs/agent-director.md, docs/agent-director-pr-merge.md, and docs/FEATURES.md if the user-visible director scope changes materially.

Acceptance:

Add tests proving backlogRefresh or its factored helper folds open PRs into the director ledger/status without dropping open issues.
Add tests proving non-merge-eligible open PRs are not silently discarded just because directorMergeEligibility would skip them.
Add tests or docs proving PR entries do not get blindly dispatched as plain issue work without PR-specific seed/context.

Closes this issue when landed.

Director's managed headless burndown currently refreshes only open issues via `listOpenIssues` / `backlogRefresh`. Open PRs are handled by a separate `director merge` sweep, and only the narrow `pull-request-and-merge` marker path can auto-merge. That leaves ordinary open PRs invisible to the interactive director backlog even when they are the actual work blocking release. Motivating example: PR #773 was open for issue #735, but `ward agent director merge --repo coilyco-flight-deck/ward --dry-run` skipped it because the PR body lacked `ward.workflow: pull-request-and-merge`. The director backlog also did not surface it as headless work because PRs are not folded into the managed scope. Request: add open PRs to the director-managed headless automated burndown scope. Expected behavior: * Director refresh includes open PRs alongside open issues for each scoped repo. * PR entries are visible in `backlogPrintStatus` / dry-run output with enough identity to distinguish `PR #N` from issue `#N`. * PRs that already have a merge-authorized `pull-request-and-merge` marker can continue through the existing narrow auto-merge lane. * Ordinary open PRs should still be tracked and surfaced as work: if checks fail, stale, or review/merge state blocks them, director should queue/surface the PR follow-up instead of reporting an empty headless lane. * The implementation should avoid dispatching an engineer against a PR as if it were the original issue unless the seed explicitly tells the worker to update the existing PR branch and preserve the PR boundary. Implementation notes from the current code: * `cmd/ward/agent_director.go` `backlogRefresh` only calls `cl.listOpenIssues` and ranks issue labels. * `cmd/ward/forgejo_ops.go` already has `listOpenPullRequests` for the merge lane. * `cmd/ward/agent_director_merge.go` holds the current merge eligibility policy. Keep that policy for actual merge authority, but make non-eligible open PRs visible to the director loop. * Update docs: `docs/agent-director.md`, `docs/agent-director-pr-merge.md`, and `docs/FEATURES.md` if the user-visible director scope changes materially. Acceptance: * Add tests proving `backlogRefresh` or its factored helper folds open PRs into the director ledger/status without dropping open issues. * Add tests proving non-merge-eligible open PRs are not silently discarded just because `directorMergeEligibility` would skip them. * Add tests or docs proving PR entries do not get blindly dispatched as plain issue work without PR-specific seed/context. Closes this issue when landed.

coilyco-ops commented

2026-07-09 15:50:12 +00:00

Author

Owner

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-804 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T15:50: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/ward#804 · branch issue-804 · harness codex · workflow pull-request
Run: engineer-codex-ward-804 · ward v0.493.0 · dispatched 2026-07-09T15:50:09Z
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.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-804` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T15:50: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/ward#804` · branch `issue-804` · harness `codex` · workflow `pull-request` - **Run:** `engineer-codex-ward-804` · ward `v0.493.0` · dispatched `2026-07-09T15:50:09Z` - **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.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 16:04:14 +00:00

Include open PRs in director managed burndown scope #808

coilyco-ops commented

2026-07-09 16:04:54 +00:00

Author

Owner

WARD-OUTCOME: done ✅

details

workflow: review gate skipped by ~/.ward/config.yaml default; review summary: skipped
Felt straightforward. The only surprise was the repo markdown cap on docs/agent-director.md and an unrelated pre-existing failure in the full suite, so the touched director tests were validated directly.
confidence: high
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: review gate skipped by ~/.ward/config.yaml default; review summary: skipped Felt straightforward. The only surprise was the repo markdown cap on docs/agent-director.md and an unrelated pre-existing failure in the full suite, so the touched director tests were validated directly. confidence: high follow-ups: none </details>

coilysiren closed this issue

2026-07-09 16:13:14 +00:00

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

1 participant

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/ward#804

No description provided.

Rows
Columns