Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Add hard queue-target resolution wall before PR inventory or empty-queue claims #201

New Issue
Closed
opened 2026-07-05 15:13:37 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-05 15:13:37 -05:00
Owner
Copy Link
Copy Source

Problem

Reviewer agents can check the wrong repository queue and then report “no open PRs,” even when the intended review backlog has open PRs. This creates a false stop condition and hides actionable PRs from the operator.

Observed failure

The agent repeatedly reported that Scaled-Tech-Consulting/mcp-control-plane had zero open PRs and concluded that there was nothing to review. However, the active review backlog is Scaled-Tech-Consulting/Gitea-Tools, which currently has six open PRs:

  • #195 — Add fail-closed PR inventory wall when list_prs returns an unexpected empty queue
  • #193 — Raise reviewer A-bar: capability, sweep, live-state, and role-boundary proofs
  • #192 — Add role-boundary proofs for reviewer queue workflows
  • #190 — Fix MCP registration and naming for Jenkins/GlitchTip servers and add discoverability coverage
  • #187 — Harden author-run reporting and mutation capability proof
  • #181 — Add fail-closed branch-identity proofs for author commit/push workflow

Required wall

Before any PR inventory, review selection, or empty-queue report, the workflow must resolve and lock the intended queue target.

The queue target must be derived from explicit operator context, including:

  • repo name mentioned by the user;
  • PR numbers/titles supplied by the user;
  • current working project context;
  • previous handoff target;
  • remote/owner/repo configured for the active task.

If these sources conflict, the agent must fail closed with a target-resolution blocker. It must not silently inventory a different repo.

Required behavior

  • If the operator provides PR numbers or PR titles, the agent must verify those PRs exist in the resolved repo before claiming the queue is empty.
  • If the agent inventories mcp-control-plane but the supplied PRs are in Gitea-Tools, the result must be target_repo_mismatch, not trusted_empty.
  • Empty-queue claims are forbidden unless the queue target has first been resolved and locked.
  • The final report must include the locked queue target: remote, owner, repo, source of target resolution, and whether user-provided PRs were reconciled.

Acceptance criteria

  • Add a test where the user supplies open Gitea-Tools PRs but the agent inventories mcp-control-plane; expected result: target_repo_mismatch.
  • Add a test where list_prs returns empty for the wrong repo; expected result: blocked, not “no open PRs.”
  • Add a test where the user says “currently we have 6 open PRs” and provides PR numbers; expected result: the workflow must reconcile those PR numbers before stopping.
  • Add a test where repo context is ambiguous between mcp-control-plane and Gitea-Tools; expected result: fail closed and require target clarification or explicit operator target.
  • Empty-queue reports must include queue_target_lock.status == resolved.
  • pr_inventory_trust_gate must consume the queue target lock result; it cannot return trusted_empty if the repo target is unresolved or contradicted by operator context.

Suggested implementation

Add a queue_target_lock or resolve_pr_queue_target helper that runs before pr_inventory_trust_gate. The trust gate should refuse to evaluate empty inventory unless the target lock is resolved and consistent with operator-provided PR context.

Related

  • #194: false-empty PR queue reports when Gitea-Tools has open PRs.
  • #196: enforce PR inventory trust gate in the live reviewer queue path.
  • #198: require explicit trust-gate status in empty-queue reports.
  • #197: terminal hard-stop purity after reviewer capability denial.
## Problem Reviewer agents can check the wrong repository queue and then report “no open PRs,” even when the intended review backlog has open PRs. This creates a false stop condition and hides actionable PRs from the operator. ## Observed failure The agent repeatedly reported that `Scaled-Tech-Consulting/mcp-control-plane` had zero open PRs and concluded that there was nothing to review. However, the active review backlog is `Scaled-Tech-Consulting/Gitea-Tools`, which currently has six open PRs: * #195 — Add fail-closed PR inventory wall when list_prs returns an unexpected empty queue * #193 — Raise reviewer A-bar: capability, sweep, live-state, and role-boundary proofs * #192 — Add role-boundary proofs for reviewer queue workflows * #190 — Fix MCP registration and naming for Jenkins/GlitchTip servers and add discoverability coverage * #187 — Harden author-run reporting and mutation capability proof * #181 — Add fail-closed branch-identity proofs for author commit/push workflow ## Required wall Before any PR inventory, review selection, or empty-queue report, the workflow must resolve and lock the intended queue target. The queue target must be derived from explicit operator context, including: * repo name mentioned by the user; * PR numbers/titles supplied by the user; * current working project context; * previous handoff target; * remote/owner/repo configured for the active task. If these sources conflict, the agent must fail closed with a target-resolution blocker. It must not silently inventory a different repo. ## Required behavior * If the operator provides PR numbers or PR titles, the agent must verify those PRs exist in the resolved repo before claiming the queue is empty. * If the agent inventories `mcp-control-plane` but the supplied PRs are in `Gitea-Tools`, the result must be `target_repo_mismatch`, not `trusted_empty`. * Empty-queue claims are forbidden unless the queue target has first been resolved and locked. * The final report must include the locked queue target: remote, owner, repo, source of target resolution, and whether user-provided PRs were reconciled. ## Acceptance criteria * Add a test where the user supplies open Gitea-Tools PRs but the agent inventories mcp-control-plane; expected result: `target_repo_mismatch`. * Add a test where `list_prs` returns empty for the wrong repo; expected result: blocked, not “no open PRs.” * Add a test where the user says “currently we have 6 open PRs” and provides PR numbers; expected result: the workflow must reconcile those PR numbers before stopping. * Add a test where repo context is ambiguous between `mcp-control-plane` and `Gitea-Tools`; expected result: fail closed and require target clarification or explicit operator target. * Empty-queue reports must include `queue_target_lock.status == resolved`. * `pr_inventory_trust_gate` must consume the queue target lock result; it cannot return `trusted_empty` if the repo target is unresolved or contradicted by operator context. ## Suggested implementation Add a `queue_target_lock` or `resolve_pr_queue_target` helper that runs before `pr_inventory_trust_gate`. The trust gate should refuse to evaluate empty inventory unless the target lock is resolved and consistent with operator-provided PR context. ## Related * #194: false-empty PR queue reports when Gitea-Tools has open PRs. * #196: enforce PR inventory trust gate in the live reviewer queue path. * #198: require explicit trust-gate status in empty-queue reports. * #197: terminal hard-stop purity after reviewer capability denial.
jcwalker3 commented 2026-07-05 15:35:19 -05:00
Author
Owner
Copy Link
Copy Source

Duplicate — closing. Exact-title triple with #200 and #202 ("Add hard queue-target resolution wall before PR inventory or empty-queue claims"), filed by three parallel author sessions within minutes; #200 (lowest number, oldest) is the canonical copy. #202 was already closed as a duplicate by its authoring session; closing this copy completes the consolidation so exactly one queue-target wall issue remains open.

Content audit before closing: this copy's body is materially identical to #200. Its only delta — the #197 cross-reference in Related — is already preserved on #200 (consolidation comment, including the #202 salvage: build on review_proofs.resolve_repos_from_user_reference from #184/PR #185, and target_repo_mismatch reports must follow #197 terminal-report purity). Nothing is lost by closing.

Closed under jcwalker3 / prgs-author per operator dedup directive; capability proof: gitea_resolve_task_capability(close_issue) → allowed_in_current_session: true, gitea_resolve_task_capability(comment_issue) → allowed_in_current_session: true.

Duplicate — closing. Exact-title triple with #200 and #202 ("Add hard queue-target resolution wall before PR inventory or empty-queue claims"), filed by three parallel author sessions within minutes; #200 (lowest number, oldest) is the canonical copy. #202 was already closed as a duplicate by its authoring session; closing this copy completes the consolidation so exactly one queue-target wall issue remains open. Content audit before closing: this copy's body is materially identical to #200. Its only delta — the #197 cross-reference in Related — is already preserved on #200 (consolidation comment, including the #202 salvage: build on `review_proofs.resolve_repos_from_user_reference` from #184/PR #185, and `target_repo_mismatch` reports must follow #197 terminal-report purity). Nothing is lost by closing. Closed under `jcwalker3 / prgs-author` per operator dedup directive; capability proof: `gitea_resolve_task_capability(close_issue)` → `allowed_in_current_session: true`, `gitea_resolve_task_capability(comment_issue)` → `allowed_in_current_session: true`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#201