[cgwalters-bot]

On a pull request the bot did not open, the poll now gives the operator's request a tracking issue in the dispatch repository, because the dispatch workflow refuses triage and research runs whose item is a pull request (bootc-dev/bootc#2571 hit this). The run takes that issue as its item and answers there. The claim on the pull request records the issue and links to it, so later comments are quoted on the same issue. The bot's own pull requests still get fix rounds, and a /bot or @BOT line asking for research or an investigation gets a research run in place of triage.

Reuse trusts no claim on its face. Upstream admins can edit the bot's comments, so a mapped issue is reused only when it is open, is in the tracker, was opened by the bot and has this pull request's title. Otherwise a new issue is opened. This stops a forged claim from pointing a run at some other tracker issue.

Verified: cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked, the three CI cargo run commands and agentic-job handback scan all exited 0. Nothing was run against live GitHub.

Left unverified: whether the bot's token can open issues in the tracker, and whether a run on the tracker issue can read the upstream pull request.

Self-review: 1 pass, no blocker. Afterwards I added the check that a reused issue is still in the tracker, which catches a transferred issue. Open follow-ups:

• A mapped issue that returns 404, because it was deleted or an upstream admin forged its number, fails each try. That pull request's later requests are dropped after three tries; it does not fall back to a new issue.
• A retry after a refused dispatch quotes the same comments on the issue again. A 5xx while creating the issue is retried like a refusal, so it can open a duplicate (three at most).
• The tracker issue quotes the comments word for word. A private repository in operatorComments paired with a public tracker would publish them.
• research is picked by keyword. "no research needed" on a line addressed to the bot still counts.

Closes #106

Generated by dispatch · ◷

[github-actions]

VERDICT: CHANGES — tracking can disclose private pull-request comments.

Reviewed admitted head: e4df253d017aca49aa4901a5fbc42a75075da53b (against merge base 60cfeeecc828c65d7153646e4ffd1a714cf9d2b4).

• blocker — crates/board-forge/src/poll/comments.rs:779–820: Creating or updating a tracking issue copies the operator's comments and the source PR URL into dispatch_repo without checking either repository's visibility. operatorComments accepts repository and organization scopes, including private repositories accessible to the polling token; an organization wildcard can also acquire private repositories later. With a public dispatch repository, an ordinary operator comment on somebody else's private PR now publishes its contents publicly, even without an explicit bot request. This is the worst new outcome of this change, and neither scope validation nor the mapping's author/title checks prevent it. Fail closed before quoting private/internal source material into a less restricted repository (or explicitly restrict this feature to verified public sources), including the reuse path; add negative coverage for private source/public tracker.

• important — crates/board-forge/src/poll/comments.rs:791–792: A missing mapped issue propagates the GET error instead of treating the mapping as unusable. Deleting the tracking issue, or an upstream administrator editing the bot's claim to name a nonexistent issue, makes every subsequent request reuse that broken mapping. Each request is retried three times and then marked handled without ever dispatching. Treat a definitive 404 as an invalid mapping and create a replacement, while keeping authentication and transient failures distinguishable. Cover a deleted mapping and subsequent comments.

• important — crates/board-forge/src/poll/comments.rs:717–721: The new pre-dispatch claim rewrite can permanently consume a request without starting its run. If issue creation succeeds but this PATCH fails (for example a transient API error), the original winning claim still lists comments without refused; handled() consequently treats them as completed on the next pass, although dispatch was never reached. Persist a recoverable pre-dispatch state or otherwise make this failure retryable, and cover failure of this PATCH specifically.

Review was static; no existing test suites, formatters, linters, or CI results were run or consulted.

Generated by review for #107 at e4df253

[cgwalters-bot]

Fix round 1 of 2 for e4df253d017a: claimed.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters-bot]

Fix round 1 of 2 for e4df253d017a: run.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters-bot]

✅ dispatch ended well. Result: #107

[github-actions]

VERDICT: APPROVE

Reviewed admitted head eedfbdfd1880344a0e389b6f98d8d0a836729961 against merge base 60cfeeecc828c65d7153646e4ffd1a714cf9d2b4 of origin/main. No blocker found.

Follow-ups

• [important] crates/board-forge/src/poll/comments.rs:724–731, 848–860: an ambiguous failure of the issue-creation POST is treated as a refused attempt, even when GitHub may already have created the issue. Because its number was never recorded, the next attempt opens another issue; repeated lost responses can leave three tracking issues for one request and exhaust retries without dispatching it. Consider recovering an existing matching issue before retrying creation, and cover a server-side creation followed by a lost/error response.

The routing change can publish operator comments and start a run against a tracker issue. The new public-repository check blocks copying private/internal PR comments through this path; reuse requires an open, bot-authored issue in the configured tracker with the source-specific title, rather than trusting an upstream-editable claim alone. Dispatch and request budgets remain in place, and the change does not authorize executing the upstream PR's code.

Read-only source/diff review only; no test suites, formatters, linters, or CI-result lookups were run.

Generated by review for #107 at eedfbdf