Investigate false-empty PR queue reports when Gitea-Tools has open PRs #194

New Issue

2026-07-05T14:55:07-05:00

jcwalker3 commented

2026-07-05 14:55:07 -05:00

Problem

A Claude run was asked: “What do you think is best at this moment to work on? PRs or issues?”

It answered:
“PR queue empty — just proved zero open PRs. So issues.”

That appears wrong. Gitea-Tools has multiple open PRs, while the Claude response only discussed the mcp-control-plane issue backlog.

Observed behavior

Claude claimed the PR queue was empty.
It then listed only mcp-control-plane open issues.
It recommended starting mcp-control-plane issue #70 as author work.
It did not report Gitea-Tools open PRs.
It appears to have checked only Scaled-Tech-Consulting/mcp-control-plane or mis-scoped the PR inventory.
This would incorrectly route the operator away from reviewing existing Gitea-Tools PRs and toward starting new issue work.

Known expected state

Gitea-Tools has open PRs, including recent queue items such as:

mcp-control-plane may have zero open PRs, but that does not mean the configured PR queue is empty.

Required investigation

Determine whether the tool call only listed PRs for mcp-control-plane.
Determine whether repo-name disambiguation routed “PR queue” incorrectly.
Determine whether the workflow treated a single-repo zero result as a global queue-empty result.
Determine whether the final report omitted checked repositories and per-repo counts.
Determine whether the prompt/template still allows “PR queue empty” without proving all configured repos were inventoried.
Determine whether Gitea-Tools PRs were filtered out incorrectly due to author/self-authorship, profile, state, mergeability, or stale status.

Required behavior

For general questions like:
- “What is best to work on?”
- “PRs or issues?”
- “What should we work on next?”
- “continue the queue”
  the workflow must inventory all configured repositories:
- Scaled-Tech-Consulting/Gitea-Tools
- Scaled-Tech-Consulting/mcp-control-plane
The workflow must report per-repo PR counts before recommending issues.
It must never say “PR queue empty” unless all configured repos were checked and returned zero open PRs.
If one repo has zero PRs and another has open PRs, the correct recommendation should usually be PR review, not new issue implementation.
If open PRs exist but are stale/ineligible, the workflow must say:
- open PRs exist
- why each is blocked
- what author/reviewer action is needed next
If the active profile is prgs-author, the workflow may inventory PRs but must not review/merge. It should recommend a reviewer session for eligible PRs instead of pretending the queue is empty.
If the active profile is prgs-reviewer, the workflow should pick the next eligible PR and proceed unless blocked.

Tests / harness assertions

Given mcp-control-plane has 0 open PRs and Gitea-Tools has open PRs, “PR queue empty” is invalid.
A single-repo zero result cannot support a global “issues are best” recommendation.
“PRs or issues?” must check both configured repos.
Open PRs authored by jcwalker3 must still be reported under author profile, even if review/merge is blocked.
Recommendation logic must prefer clearing eligible open PRs over starting new issue work.
Final report must include repositories checked, per-repo open PR counts, and whether inventory was complete or scoped.

Acceptance criteria

A queue recommendation earns an A only when it proves complete multi-repo PR inventory before choosing PRs vs issues. It must not recommend issue work while open eligible PRs exist in any configured repo.

### Problem A Claude run was asked: “What do you think is best at this moment to work on? PRs or issues?” It answered: “PR queue empty — just proved zero open PRs. So issues.” That appears wrong. Gitea-Tools has multiple open PRs, while the Claude response only discussed the mcp-control-plane issue backlog. ### Observed behavior * Claude claimed the PR queue was empty. * It then listed only mcp-control-plane open issues. * It recommended starting mcp-control-plane issue #70 as author work. * It did not report Gitea-Tools open PRs. * It appears to have checked only `Scaled-Tech-Consulting/mcp-control-plane` or mis-scoped the PR inventory. * This would incorrectly route the operator away from reviewing existing Gitea-Tools PRs and toward starting new issue work. ### Known expected state Gitea-Tools has open PRs, including recent queue items such as: * PR #181 * PR #186 * PR #187 * PR #190 * PR #192 * PR #193 mcp-control-plane may have zero open PRs, but that does not mean the configured PR queue is empty. ### Required investigation 1. Determine whether the tool call only listed PRs for `mcp-control-plane`. 2. Determine whether repo-name disambiguation routed “PR queue” incorrectly. 3. Determine whether the workflow treated a single-repo zero result as a global queue-empty result. 4. Determine whether the final report omitted checked repositories and per-repo counts. 5. Determine whether the prompt/template still allows “PR queue empty” without proving all configured repos were inventoried. 6. Determine whether Gitea-Tools PRs were filtered out incorrectly due to author/self-authorship, profile, state, mergeability, or stale status. ### Required behavior 1. For general questions like: * “What is best to work on?” * “PRs or issues?” * “What should we work on next?” * “continue the queue” the workflow must inventory all configured repositories: * `Scaled-Tech-Consulting/Gitea-Tools` * `Scaled-Tech-Consulting/mcp-control-plane` 2. The workflow must report per-repo PR counts before recommending issues. 3. It must never say “PR queue empty” unless all configured repos were checked and returned zero open PRs. 4. If one repo has zero PRs and another has open PRs, the correct recommendation should usually be PR review, not new issue implementation. 5. If open PRs exist but are stale/ineligible, the workflow must say: * open PRs exist * why each is blocked * what author/reviewer action is needed next 6. If the active profile is `prgs-author`, the workflow may inventory PRs but must not review/merge. It should recommend a reviewer session for eligible PRs instead of pretending the queue is empty. 7. If the active profile is `prgs-reviewer`, the workflow should pick the next eligible PR and proceed unless blocked. ### Tests / harness assertions * Given mcp-control-plane has 0 open PRs and Gitea-Tools has open PRs, “PR queue empty” is invalid. * A single-repo zero result cannot support a global “issues are best” recommendation. * “PRs or issues?” must check both configured repos. * Open PRs authored by `jcwalker3` must still be reported under author profile, even if review/merge is blocked. * Recommendation logic must prefer clearing eligible open PRs over starting new issue work. * Final report must include repositories checked, per-repo open PR counts, and whether inventory was complete or scoped. ### Acceptance criteria A queue recommendation earns an A only when it proves complete multi-repo PR inventory before choosing PRs vs issues. It must not recommend issue work while open eligible PRs exist in any configured repo.

sysadmin commented

2026-07-05 14:57:52 -05:00

Positive Baseline for Queue Recommendation

Evidence:
A Claude author-profile session was asked: “What do you think is best at this moment to work on? PRs or issues?”

It correctly answered: PRs.

Positive behavior:

Did a live queue check before answering.
Correctly identified 5 open Gitea-Tools PRs and 0 open mcp-control-plane PRs.
Did not falsely claim the whole PR queue was empty.
Correctly identified that PR review is the bottleneck.
Correctly warned that starting new issue work would worsen the queue and increase conflict risk.
Correctly identified overlapping/conflicting files:
- review_proofs.py
- SKILL.md
Correctly distinguished mergeable PRs from conflicted PRs:
- #181 mergeable
- #190 mergeable
- #192 mergeable
- #187 conflicted
- #193 conflicted
Correctly noted that the active author profile cannot review/merge.
Correctly suggested that author-side remediation should focus only on the session’s own conflicted PR #193, not another session’s #187.
Correctly flagged PR #190’s issue-link/title ambiguity as a reviewer concern.

Remaining proof/reporting gaps:

Identity/profile proof should be explicit: The report should include authenticated username, profile, role, and allowed/forbidden operations.
PR inventory should include full fields:

PR number
issue
author
branch
base
head SHA
mergeability
stale/conflict status
same-session authorship evidence, if claimed

Same-session authorship claims need evidence: The report says #181 and #193 are “me / this session,” but future reports must show the evidence source.
Author-remediation recommendation should become a structured handoff: If the active profile is author and PR review is blocked, the report should either:

recommend a reviewer session for mergeable PRs, or
produce an author-continuation handoff for the author’s own stale/conflicted PR.

Required behavior:

For “PRs or issues?” the workflow must inventory all configured repos and recommend PRs first when eligible/open PRs exist.
If active profile cannot review, it must not say “issues are best” just because it cannot merge.
If open PRs are conflicted/stale and authored by the current author session, author-side rebase/update is a valid next action only in explicit continuation mode.
If open PRs are authored by other sessions, do not update them; recommend the owning author or reviewer action.

Acceptance criteria:
A queue recommendation earns an A when it proves complete repo inventory, gives PR-vs-issue recommendation, distinguishes reviewer work from author remediation, and includes evidence-backed ownership/session claims.

### Positive Baseline for Queue Recommendation **Evidence:** A Claude author-profile session was asked: “What do you think is best at this moment to work on? PRs or issues?” It correctly answered: PRs. **Positive behavior:** * Did a live queue check before answering. * Correctly identified 5 open Gitea-Tools PRs and 0 open mcp-control-plane PRs. * Did not falsely claim the whole PR queue was empty. * Correctly identified that PR review is the bottleneck. * Correctly warned that starting new issue work would worsen the queue and increase conflict risk. * Correctly identified overlapping/conflicting files: * `review_proofs.py` * `SKILL.md` * Correctly distinguished mergeable PRs from conflicted PRs: * #181 mergeable * #190 mergeable * #192 mergeable * #187 conflicted * #193 conflicted * Correctly noted that the active author profile cannot review/merge. * Correctly suggested that author-side remediation should focus only on the session’s own conflicted PR #193, not another session’s #187. * Correctly flagged PR #190’s issue-link/title ambiguity as a reviewer concern. **Remaining proof/reporting gaps:** 1. **Identity/profile proof should be explicit**: The report should include authenticated username, profile, role, and allowed/forbidden operations. 2. **PR inventory should include full fields**: * PR number * issue * author * branch * base * head SHA * mergeability * stale/conflict status * same-session authorship evidence, if claimed 3. **Same-session authorship claims need evidence**: The report says #181 and #193 are “me / this session,” but future reports must show the evidence source. 4. **Author-remediation recommendation should become a structured handoff**: If the active profile is author and PR review is blocked, the report should either: * recommend a reviewer session for mergeable PRs, or * produce an author-continuation handoff for the author’s own stale/conflicted PR. **Required behavior:** * For “PRs or issues?” the workflow must inventory all configured repos and recommend PRs first when eligible/open PRs exist. * If active profile cannot review, it must not say “issues are best” just because it cannot merge. * If open PRs are conflicted/stale and authored by the current author session, author-side rebase/update is a valid next action only in explicit continuation mode. * If open PRs are authored by other sessions, do not update them; recommend the owning author or reviewer action. **Acceptance criteria:** A queue recommendation earns an A when it proves complete repo inventory, gives PR-vs-issue recommendation, distinguishes reviewer work from author remediation, and includes evidence-backed ownership/session claims.

jcwalker3 referenced this issue from a commit

2026-07-05 15:06:20 -05:00

Implement fail-closed PR inventory trust gate for Issue #194

jcwalker3 referenced a pull request that will close this issue

2026-07-05 15:06:25 -05:00

Add fail-closed PR inventory wall when list_prs returns an unexpected empty queue (Issue #194) #195

jcwalker3 referenced this issue

2026-07-05 15:08:33 -05:00

Require PR inventory trust gate to be enforced in the live reviewer queue path #196

jcwalker3 referenced this issue

2026-07-05 15:11:28 -05:00

Require explicit PR inventory trust-gate status in empty-queue reports #198